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the end result is simplicity for both users and IT support staff. This paper 
describes the migration at Franklin College (Indiana) . It discusses the 
reasons for selecting Windows NT, the steps taken to complete the migration, 
the available tool set that simplified the migration, and the ways Windows NT 
has streamlined network management. Mistakes that were made and a few of the 
drawbacks encountered are discussed. The paper also covers the pre-migration 
environment; migration for the administrative users; and migration for the 
faculty and student labs. The migration at Franklin College accomplished the 
desired goals. They standardized on a single network operating system, 
streamlined network administration, and reduced the number of user databases 
from five to two. (SWC) 
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Introduction to the educational resources 

INFORMATION CENTER (ERIC)." 

In the eyes of many IT professionals “migration” is a four-letter word. The re-configuring 
and re-training that goes with a migration can be quite overwhelming. However, in the constantly 
changing world of technology, migration is not only inevitable but many times necessary for 
survival, especially when the end result is simplicity for both users and IT support staff alike. Such 
was the case at Franklin College. 

Our migration to Windows NT took place during the spring and summer of 1 996 and was 
performed in two phases, beginning with the administrative users followed by the faculty users and 
student labs. The paper will address the reasons for selecting Windows NT and the steps taken to 
complete the migration. The available tool set that simplified the migration as well as the many 
ways Windows NT has streamlined network management will be discussed. Finally, some of the 
mistakes that were made and a few of the drawbacks that were encountered will be shared as well. 



Pre-Migration Environment 



In order to put some of the decisions that were made into perspective, a brief overview of our 
environment prior to the migration would be beneficial. The primary network operating system at 
the time was Pathworks, which is Digital’s implementation of Microsoft Lan Manager. Two 
separate Pathworks servers were being maintained; one for the administrative users and one for the 
academic users (faculty and students). Both servers were running the VMS operating system with 
TGV Multinet providing our TCP/IP transport. Hence, these machines provided POP3 mail service 
for their respective constituencies in addition to file and print services. 



In addition to Pathworks, Novell Netware was being supported on a pentium-based server. 
This was dictated by our administrative database application, Campus from Applied Business 
Technologies, Inc., which at the time required Netware. The sole function of the Netware machine 
was to serve this database application. 



p ^ In terms of the clients on the network, a wide spectrum of “computing horsepower” existed 

&o on campus. Our inventory of desktop and laptop computers ranged from 90MHz pentiums with 
16MB of RAM and 1GB hard drives to 8MHz 286 computers with 1MB of RAM and a 20MB hard 
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drive. With this range in hardware capacity came a variance in software capabilities. Three versions 
of Windows and multiple versions of DOS were being supported. The existence of machines 
incapable of running any version of Windows necessitated supporting multiple versions of several 
production applications including word processing, spreadsheets and e-mail. Adding further variety 
were the handful of Macintosh machines of different types. 

All in all, no fewer than five user databases were being maintained, including two in VMS, 
two in Pathworks and one in Netware. In addition to the two network operating systems, at least 
three disk operating systems (DOS, VMS and System7) were being supported. The number of nodes 
on the network had surpassed 300 and was growing rapidly. With roughly one and a half staff 
members dedicated to network administration and the variety of platforms being supported, it was 
clear that network management needed to be streamlined. 

Why Windows NT? 

The first order of business was to select a single network operating system. At first glance, 
it would seem that Netware and not Windows NT would be the logical choice, not to mention the 
path of least resistance. With a Netware server already in place, migration from a mixed 
environment to strictly Netware would have been simple. However, several factors were examined 
and considered before our direction was chosen. 

First and foremost were the requirements of the ABT Campus software. Previous versions 
of Campus took advantage of the strong file sharing capabilities of Netware, making it a necessity. 
However, a newly released SQL version of Campus made the client / server strengths of Windows 
NT an attractive and viable option. 

The next factor considered was the network transport. With the rapid growth in Internet use 
on campus, TCP/IP had quickly become and will continue to be our standard protocol. The support 
of TCP/IP by Novell was in its infancy. Windows NT has offered TCP/IP as a transport since its 
inception. 

It should also be pointed out that our academic server was an Alpha 2000 machine capable 
of running Windows NT. While pure Netware for the Alpha was in the offing, no release date was 
available. Clearly, preserving our investment in server hardware had some influence on our decision. 

Finally, there were some concerns about Novell and its corporate direction. They had just 
purchased WordPerfect and Quattro Pro and were pouring a lot of effort into development of their 
new office suite. The fear was that they had lost focus on their true strength, the Netware network 
operating system. While Novell has since abandoned these efforts, it was cause for concern during 
our decision making process. 
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Phase I: Administration 

The first step taken was the purchase of a second Alpha. This machine would become the 
new administrative file server. It would also be our first Windows NT server and hence our Primary 
Domain Controller. The purchase of this Alpha allowed us to define a one-time migration path for 
most of our files and applications. It also gave us the luxury of being able to test the built-in 
migration tools and experiment with some of the management tools available. Furthermore, the 
addition of this server would ultimately make it possible for us to dedicate the existing Alpha as an 
SQL database server. 

Once the first Windows NT machine was up and running, we immediately installed and 
configured the Gateway Service for Netware. In a nutshell, the Gateway Service for Netware allows 
a Microsoft network client to access resources on a Netware network without any Netware client 
software installed. The Gateway Service for Netware includes the Netware Migration Tool which 
performs numerous migration functions such as: 

• account and group transfers from Netware to Windows NT, 

• file and directory transfers from Netware to Windows NT, and 

• preservation of effective rights (permissions) on transferred files and directories. 

The Migration Tool also allows a trial migration to be performed in order to determine 
exactly what will be transferred and what will not. However, the one thing the Migration Tool does 
not do is magically turn a Netware server into a Windows NT server. 

After using the Migration Tool to transfer all of our Netware accounts and groups to 
Windows NT, we configured a Windows NT client and used it to simultaneously connect to a 
Pathworks share and an NT share. In the Pathworks environment, most of our PC applications were 
installed in a single share. The contents of this share were copied to a corresponding NT share and 
then tested. Fortunately, all of these applications tested successfully and none had to be installed 
from scratch on the NT server. A similar procedure was used to copy and test the Campus software 
with similar results. 

It was decided that Windows for Workgroups (3.1 1) would be the minimum version of 
Windows supported. Hence, many of the administrative PCs would need to be upgraded. In 
addition, the nature of the Campus software prevents a one group at a time migration. As a result, 
we were forced to create dual configurations on approximately 60 administrative PCs running 
version 3.1 of Windows. This process included renaming the current Windows and network 
configuration, installing and testing a new Windows for Workgroups configuration, renaming the 
newly installed configuration and then restoring the previous configuration. 

Once all the clients had been prepared, we were ready to implement Windows NT for the 
administrative users. We began by recopying the Campus data files. The Netware server was then 
shut down, the Netware software removed and Windows NT installed. Lastly, we went back to each 
client PC to invoke the Windows for Workgroups configuration and remove the old Windows and 
Pathworks configuration. 
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This phase of the migration began in late February and was completed in early April of the 
1 996 spring semester. The second phase, which included the faculty and all the student labs, would 
be conducted during the summer months, beginning in early June. Consequently, the two months 
in between were used to address the issues that arose following the administrative implementation 
and to plan the steps to be carried out in Phase II. 

Phase II: Faculty & Student Labs 

Several factors influenced the planning and implementation of Phase II. First of all, only 
a portion of the faculty are present during the summer months. Thus, higher priority was given to 
those on campus. Also, one of our student labs was scheduled for use during summer school and 
special accommodations would have to be provided for that lab and the students using it. Moreover, 
the acquisition of more than 75 new PCs resulted in a massive installation and redistribution effort 
that had to be coordinated with the migration. 

Only a handful of the faculty had access to the Netware server and the Campus software. 
Therefore, most of the faculty accounts and groups were not created by the Migration Tool in Phase 
I and had to be created manually. On the other hand, this also meant that faculty PCs did not have 
to be dual configured as the administrative PCs were. They were merely prioritized then migrated 
one after another. The migration process simply entailed upgrading the Windows software and 
configuring the network software for Windows NT. In fact, many faculty members received 
computer upgrades as a result of the redistribution project. Their upgrade computer would be 
configured before being delivered and their old computer either taken away for further redistribution 
or simply taken away. 

In terms of the student labs, the migration to Windows NT brought about the need to 
reevaluate some of our configuration standards. Prior to the migration our lab machines were all 
configured with a utility called Iron Clad, which essentially write-protected the hard drive and 
theoretically provided virus protection. In reality, this program made the slightest configuration 
change quite time consuming and proved not to be completely virus proof. Consequently, we 
removed Iron Clad and replaced it with Norton Anti-Virus. The hard drives are no longer write- 
protected but the critical configuration and initialization files are stored on a write-protected network 
share and restored each time a PC re-boots. 

The redistribution project afforded us the opportunity to add a few specialized servers to our 
environment. The first of these servers was dedicated to electronic mail. The POP3 server software 
selected was IMail Server for NT from Ipswitch. This product uses its own user database, but we 
were able to export the Windows NT user database and import it to IMail fairly easily. The second 
specialized server was designated our World Wide Web server and uses the Microsoft Internet 
Server software. 

The final step of Phase II was to reformat the academic Pathworks server and configure it 
with Windows NT and Microsoft SQL Server. The old administrative server continues to function 
as our primary Domain Name Service server on the Internet. It is also our Kerberos server for 
college personnel with dial-in access. 
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Tools of the Trade 

There is a plethora of tools, services and utilities that greatly simplify migration to and 
management of Windows NT. The Gateway Service for Netware, while not intended to provide a 
permanent solution, makes the transition from Netware to NT extremely easy. Other built-in 
services such as Dynamic Host Configuration Protocol (DHCP), which dynamically allocates IP 
addresses, and Windows Internet Name Service (WINS), which provides a dynamic database of 
NETBIOS name to IP address mappings, offer tremendous management time savings. Services for 
Macintosh makes sharing files between PCs and Macs easy. 

Another feature to take full advantage of is the login scripts. Each time a user logs on to the 
network, their record in the user database is checked and any specified login script is executed. The 
login script can be used to connect shares, map a home directory, copy configuration files (as is done 
in our student labs) and perform many other tasks. 

One of the "extras" that comes highly recommended is the Resource Kit for Windows NT. 
This kit provides supplemental documentation and includes a CD with numerous useful utilities. 
Some examples include an account creation utility, a Windows-based command scheduler, a batch 
file user input utility and an Internet name service lookup utility. 

Drawbacks and Mistakes 

There were not many, but we did encounter some drawbacks. Of primary concern to us was 
the lack of any supported Domain Name Service software. However, DNS server software is 
provided and supported in version 4.0 of Windows NT. The lack of a supported POP3 mail server 
that uses the NT user database for authentication has added some extra overhead to our environment 
as well. Some of the other applications and utilities that we continue to run in the VMS environment 
because an NT equivalent does not exist are Kerberos, which is used to validate dial-in users, CSO, 
which is an e-mail address lookup utility, and the VMS command line multi-key sort utility. 

In retrospect, we found a number of things we could have planned or done better and more 
efficiently. We could have tested Windows for Workgroups more thoroughly and possibly 
anticipated some of the performance problems that emerged. A lot of post migration adjustments 
could have been eliminated had DHCP and WINS been implemented initially. Such was the case 
with a number of features that we discovered during the course of the migration. 

Conclusion 

In short our migration accomplished the desired goals. We have standardized on a single 
network operating system. Administration of the network is quite manageable and streamlined. The 
number of user databases has been reduced from five to two. In the near future we hope to migrate 
to a new mail system that will reduce this to a single user database. Client configuration is extremely 
simple and we have narrowed the scope of applications being supported. All in all, the trials and 
tribulations endured throughout the migration have been repaid tenfold in peace of mind. 
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